home *** CD-ROM | disk | FTP | other *** search
/ Aminet 45 / Aminet 45 (2001)(GTI - Schatztruhe)[!][Oct 2001].iso / Aminet / game / role / ldmud-3.2-bin.lha / mud / doc / concepts / native < prev    next >
Text File  |  2001-04-06  |  12KB  |  252 lines
  1. CONCEPT
  2.         driver modes / native driver mode
  3.  
  4. DESCRIPTION
  5.         During the evolution of LPMud there has been a hiatus as the
  6.         old driver became too restricting for the demands of modern
  7.         muds: it did a lot of things the mudlib could do better or
  8.         completely different. Removing these things from the driver
  9.         weren't a problem, but to keep compatible with the existing
  10.         mudlibs (namely the well-known 2.4.5 lib), it was possible to
  11.         undo these changes. First by setting a runtime option, then
  12.         by compiling the driver either in 'compat' or in 'native'
  13.         mode.
  14.  
  15.         Starting with 3.2.1, the distinction between compat and native
  16.         mode is more and more transferred into the mudlib, with the
  17.         future goal of having a modeless driver. Starting with 3.2.7,
  18.         native mode no longer exists as such.
  19.  
  20.         The main mode of the driver is determined at compile time
  21.         by preprocessor symbols to be defined/undefined in config.h:
  22.  
  23.           COMPAT_MODE: when defined, the compat mode specifics are activated.
  24.  
  25.         Additional modifications can be achieved by the specification
  26.         of commandline arguments (most of them have a default setting
  27.         entry in config.h as well):
  28.  
  29.           strict-euids: when active, euid usage is enforced.
  30.  
  31.         Following is the description of the changes (de) activated by
  32.         these defines. A shorthand notation is used: 'compat' means
  33.         'if COMPAT_MODE is defined' and '!compat' means 'if
  34.         COMPAT_MODE is not defined', etc.
  35.  
  36.  
  37.         Predefined Preprocessor Symbols
  38.           If compat, the symbols COMPAT_FLAG and __COMPAT_MODE__ are
  39.           defined for all LPC programs.
  40.           If strict-euids, the symbol __STRICT_EUIDS__ is defined
  41.           for all LPC programs.
  42.           For compatibility reasons, the symbol __EUIDS__ is defined
  43.           for all LPC programs all the time.
  44.  
  45.  
  46.         Preloading Of Objects
  47.           The driver has the possibility to preload objects before the
  48.           game is actually opened to the world. This is done by
  49.           calling master->epilog(), which has to return 0 or an array.
  50.           If its an array, its elements (as long as they are strings)
  51.           are given one by one as argument to master->preload() which
  52.           may now preload the objects (or do anything else).
  53.           Up to 3.2, compat mode used a different scheme: the file
  54.           INIT_FILE (defined in config.h) was read and each line
  55.           interpreted as filename of an object to preload. After this
  56.           was done, master->epilog() was called. This was dumped in
  57.           3.2.1 as it can be simulated by the master.
  58.  
  59.  
  60.         Initialisation Of Objects
  61.           Since 3.2.1, it is task of the mudlib (through the driver
  62.           hooks) to call the initialisation lfuns in newly created
  63.           objects, so the following table applies only up to 3.2:
  64.  
  65.                   mode        : init call : reset call
  66.            --------------------------------------------
  67.             !compat & !native :  create() :  reset(1)
  68.             !compat &  native :  create() :  reset()
  69.              compat & !native :  reset(0) :  reset(1)
  70.              compat &  native :  reset(0) :  reset(1)
  71.         
  72.           If INITIALIZATION_BY___INIT was defined, the lfun __INIT()
  73.           is called first on creation to initialize the objects
  74.           variables.
  75.  
  76.  
  77.         Movement Of Objects
  78.           Since 3.2.1, the efun move_object() is implemented in the
  79.           mudlib through driver hooks and the set_environment() efun.
  80.           move_object() itself exists just for convenience and
  81.           compatibility.
  82.  
  83.           Before 3.2.1, move_object() could applied only to this_object() as
  84.           the object to move if in native mode, and called the lfun
  85.           exit() in the old environment if in compat mode. As a side
  86.           effect, the lfun exit() may not be target of add_action()s
  87.           in compat mode.
  88.  
  89.           In !native mode, objects may be moved using the transfer()
  90.           efun. It does make assumptions about the design of the
  91.           mudlib, though, as it calls the lfuns query_weight(),
  92.           can_put_and_get(), get(), prevent_insert() and add_weight().
  93.  
  94.  
  95.         Efuns In General
  96.           creator(), transfer()
  97.             These exist only in compat mode (creator() is
  98.             identical with getuid() from !compat mode).
  99.  
  100.           getuid()
  101.             Exists only in !compat mode (getuid() is identical with
  102.             creator()).
  103.  
  104.           file_name(),function_exists()
  105.             In !compat mode, the returned filenames start with a
  106.             leading '/', in compat mode they don't.
  107.  
  108.           parse_command()
  109.             This command exists in two versions: the old is used with
  110.             compat, the new with !compat. However,
  111.             SUPPLY_PARSE_COMMAND must be defined in config.h in both
  112.             cases (this efun is not very useful at all).
  113.  
  114.           process_string()
  115.             If this_object() doesn't exist, it defaults to this_player()
  116.             and receives the backbone uid (returned by master->get_bb_uid())
  117.             as euid. If strict-euids, this uid must not be 0.
  118.  
  119.           snoop()
  120.             Besides that the call is verified with a call to
  121.             master->verify_snoop(), up to 3.2 the snooper has to have
  122.             a non-zero euid.
  123.  
  124.         Userids and Effective Userids
  125.           This is probably the most important difference between the
  126.           modes.
  127.  
  128.           LPMud always had userids (uids) attributing the objects,
  129.           though they were called 'creator names' in compat mode.
  130.           Internally, the compat mode uses the 'creator names' as
  131.           (e)uid.
  132.  
  133.           With the introduction of native mode, additionally
  134.           'effective userids' (euids) were introduced to improve
  135.           security handling (which was only a partial success).
  136.           The hardcoded handling of euids and uids was quite complex
  137.           and too mudlib-insensitive, so most of it got moved from the
  138.           driver into the mudlib with 3.2.1.
  139.  
  140.           In strict-euids mode, only objects with a non-zero euid may load
  141.           or create new objects.
  142.  
  143.           --- 3.2.1 and after ---
  144.  
  145.             Userids of the Master
  146.               The masters (e)uid is determined by a call to
  147.               master->get_master_uid().
  148.               In strict-euids mode, the result has to be a string,
  149.                 otherwise the driver won't start up at all. If the result is
  150.                 valid it is set as the masters uid and euid.
  151.               In !strict-euids mode, the result may be any value: 0 or a
  152.                 string are treated as the uid to set, a non-zero integer
  153.                 leads to the use of the uid set in the default 'global'
  154.                 wizlist entry, and any other value defaults to 0.
  155.                 The euid is either set to the returned string (if any),
  156.                 or to 0.
  157.               The masters uid is determined only on startup this way,
  158.               at runtime the uids of a reloaded master determined as
  159.               for every object by a call to the appropriate driver
  160.               hooks.
  161.  
  162.             Userids of New Objects
  163.               To determine the (e)uids for a new object (loaded or
  164.               inherited, or cloned), the appropriate driver hook is
  165.               evaluated (H_LOAD_UIDS, H_CLONE_UIDS) and the result set
  166.               as (e)uid. The result may be a single value, in which case the
  167.               euid is set to 0, or an array ({ uid, euid }).
  168.               In strict-euids mode, both uid and euid must be 0 or a string,
  169.                 any other value causes the load/clone to fail.
  170.               In !strict-euids mode, the uid (however returned) may also be
  171.                 a non-zero integer to use the uid of the global
  172.                 wizlist entry as uid. The euid is then
  173.                 set to either 0 or the second entry of the returned
  174.                 array if it's a string.
  175.  
  176.           --- 3.2 ---
  177.  
  178.             LPMud <= 3.2 in !compat mode has the algorithm deciding _which_
  179.             (e)uid to set hardcoded into the driver. For this it
  180.             features two builtin uids: the root uid (queried by a call
  181.             to master->get_root_uid()) and the backbone uid
  182.             (master->get_bb_uid()). Both uids should be a string: if
  183.             not, the driver in native mode will terminate, else print
  184.             a warning to stderr. The backbone uid is queried just once
  185.             at startup.
  186.  
  187.             Userids of the Master
  188.               In compat mode, the master's (e)uid is the (e)uid as
  189.               determined for every other object as well. The following
  190.               therefore applies only to !compat mode.
  191.  
  192.               The initial (e)uid is those determined using the normal
  193.               algorithm for newly created objects (see below).
  194.               After the master being loaded, master->get_root_uid() is
  195.               called to query the (e)uid to use for real. If the
  196.               result is a string, it is used as real (e)uid, else the
  197.               default setting. In native mode, get_root_uid() must
  198.               return a string, else the driver will terminate.
  199.  
  200.             Userids of New Objects
  201.               If an object has been newly created, it is equipped with
  202.               a default uid: 0 in !native mode, "NONAME" in native
  203.               mode. The default euid (if needed) is equal to the uid,
  204.               or 0 if no master object exists.
  205.  
  206.               The basic idea is simple: the master is asked, which (e)uid
  207.               the new object should have.
  208.               Objects loaded by the game, in compat model, or by an
  209.               object of the same creator will get the suggested e/uid.
  210.               Backbone objects will get the euid of the loader.
  211.               Other objects will get 0 as euid.
  212.               The details are a bit more complicated...:
  213.  
  214.               Then master->creator_file() is asked for the 'creator
  215.               uid' (cuid) of this object. If the lfun doesn't exist,
  216.               the new object is destructed.
  217.               The cuid must be a string, the number 0 or an array of
  218.               two elements, !native mode also allows other non-array
  219.               values. If the cuid is non of these (native mode
  220.               restricts this further to the string or array), the
  221.               object is destructed again.
  222.  
  223.               If the cuid is an array of two elements ({ uid, euid }),
  224.               these are set as e/uid (non-strings are treated as 0).
  225.               If the cuid is neither string, array or the number 0,
  226.               the object gets 0 as e/uid (!native mode only).
  227.  
  228.               If the cuid is a string (all other cases are treated
  229.               above) is it always set as the objects uid. The objects
  230.               euid needs further treatment. If all following cases
  231.               (checked in the order listed here) fail, it is set to 0.
  232.  
  233.               In compat mode, the euid is set to the uid.
  234.  
  235.               In !native mode, if the object is loaded (not cloned) or
  236.               the loader has as 0 uid, the euid is set to the cuid.
  237.               Also in !native mode, if the loader has a 0 euid, the
  238.               objects euid is set to 0.
  239.  
  240.               If the cuid is equal to the loaders uid, the objects
  241.               euid is set to the cuid == uid.
  242.  
  243.               If the cuid is the backbone uid (and in !native mode the
  244.               loader has a non-zero euid), the objects e/uid are both
  245.               set to the loaders euid.
  246.  
  247.           ------
  248.  
  249.  
  250. SEE ALSO
  251.         hooks(C), uids(C), move_object(E), initialisation(LPC)
  252.